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Description 

SYSTEMS AND METHODS OF SECURING 
RESOURCES THROUGH PASSWORDS 

Background of Invention 

[0001] Field of the Invention 

[0002] The present invention relates to computer methods for 
managing secure access to protected resources. General 
methodologies within this field include password protec- 
tion, encryption, decryption, cryptography, and biomet- 
rics. 

[0003] Description of the Related Art 

[0004] The be low- referenced U.S. Patents disclose embodiments 
that were satisfactory for the purposes for which they 
were intended. The disclosures of the below-referenced 
prior U.S. Patents, in their entireties, are hereby expressly 
incorporated by reference into the present invention for 
purposes including, but not limited to, indicating the 
background of the present invention and illustrating the 



state of the art: U.S. Patent 5,944,825, "Security and Pass- 
word Mechanisms In A Database System," August 31, 
1999, U.S. Patent 5,699,514, "Access Control System With 
Lockout," December 16, 1997, U.S. Patent 6,202,158, "De- 
tection Method Of Illegal Access To Computer System," 
March 13, 2001, U.S. Patent Application 
2003/0149900A1, "System And Method For Providing 
Multi-Class Processing Of Login Requests," Published Au- 
gust 7, 2003, U.S. Patent Application 2002/0067832A1, 
"Systems, Methods and Software For Remote Password 
Authentication Using Multiple Servers," Published June 6, 

2002, U.S. Patent 5,375,244, "System And Method For 
Granting Access To A Resource," December 20, 1994. U.S. 
Patent 6,397,337, "Unified Password Prompt of A Com- 
puter System," May 28, 2002, U.S. Patent 6,601,173, 
"Multi-User Internet Access and Security System," July 29, 

2003, U.S. Patent 6,240,184, "Password Synchronization," 
May 29, 2001, U.S. Patent 5,682,475, "Method And Sys- 
tem For Variable Password Access," October 28, 1997, 
U.S. Patent 5,581,700, "Hierarchical Multiple Password Ac- 
ceptance System," December 3, 1996, U.S. Patent 
5,793,951, "Security and Report Generation Systems for 
Networked Multimedia Workstations," August 11, 1998, 



and U.S. Patent 5,931,948, "Portable Computer System 
Having Password Control Means For Holding One Or More 
Passwords Such That The Passwords Are Unreadable By 
Direct Access From A Main Procedure," August 3, 1999. 
Summary of Invention 

[0005] When a user attempts to log on to a secured computer re- 
source, his password is typically "locked out" after he en- 
ters a specified number of consecutive invalid passwords. 
The invention increments this lockout count by a variable 
amount based on comparison of a submitted invalid pass- 
word relative to a valid password. As a result, the lockout 
count is increased less severely for invalid access attempts 
which reflect typographical errors than for invalid access 
attempts more likely to stem from a hacker attack. 

[0006] Another aspect of the invention applies to an environment 
where multiple software applications share a common 
user identifier (userid). These applications store the 
userid's password in persistent storage (e.g., in a file or in 
memory). Coordinating the changing of passwords in this 
environment is difficult. One inventive solution for miti- 
gating the password coordination problem is to have mul- 
tiple valid passwords for a userid. By stratifying the expi- 
ration dates of these passwords across time, it is no 



longer necessary to coordinate each application's use of a 
password change to occur at the same time. Another em- 
bodiment for mitigating the password coordination prob- 
lem is achieved through centralized password control and 
management. This embodiment keeps track of all applica- 
tion usages of each shared userid/password in a data 
repository. This data repository contains details on the 
application and the userid/password it is using to access a 
particular resource. When a userid's password is changed, 
a program will access the data repository, find the appli- 
cations using that userid, and automatically update the 
passwords used by that application. In addition, the pro- 
gram will also automatically verify the usages of each 
shared userid/password by scanning all the applications 
at periodic intervals. 
[0007] More specifically, the invention presents a sophisticated 
method of authorizing access to an item (such as a data 
file, a server, a system, a network, a room, a building, a 
vehicle, or any other "item" that can be protected by pass- 
word). This processing begins by receiving a presented 
password (symbols, numbers, characters, sounds, tones, 
pulses, etc. entered via a signal line, keyboard, keypad, 
touch pad, audio receiver, light receiver, etc.) from an en- 



tity or user desiring access to tlie item. In this case an en- 
tity or "user" can comprise individuals, software applica- 
tions, application owners, etc. The invention compares the 
presented password with a stored password and autho- 
rizes access if the presented password exactly matches 
the stored password and denies access if the presented 
password fails to exactly match the stored password. The 
invention maintains a lockout count and blocks access to 
the item if the lockout count exceeds a predetermined 
value. The difference between denying access and block- 
ing access is that the "denying" process allows additional 
potentially valid passwords to be presented after an in- 
valid password is presented, while the "blocking" or "lock 
out" process prevents any additional passwords from be- 
ing presented (even if they are valid passwords). 
[0008] One feature is that the invention "variably" increments the 
lockout counts if the presented password fails to exactly 
match the stored password. In this process, the invention 
increments the lockout count different amounts depend- 
ing upon how closely the presented password matches the 
stored password. Thus, with this feature, the lockout 
count is incremented a lesser amount as the presented 
password matches the stored password more closely and 



is incremented a greater amount as the presented pass- 
word matches the stored password less closely. Further, 
the invention has the ability to not increment the lockout 
count at all if the presented password is the same as a 
previously presented password that was entered within a 
predetermined previous time period. 

[0009] When determining how closely the presented password 
matches the stored password, the invention evaluates 
whether the difference between the presented password 
and the stored password relates to common typographical 
errors. Further, when determining how closely the pre- 
sented password matches the stored password, the inven- 
tion classifies the difference between the presented pass- 
word and the stored password into different types of 
password errors and these different types of password er- 
rors cause the lockout count to be incremented by differ- 
ent values. For example, the different types of password 
errors can include missing characters, extra characters, 
transposed characters, incorrect upper or lower case us- 
age, no matching characters, one-quarter matching char- 
acters, one-half matching characters, etc. 

[0010] The invention also provides a methodology that allocates 
a plurality of the same passwords to a plurality of users 



who share the same userid. The invention allows continu- 
ous operation of the item being accessed by providing 
that each of the passwords has a different expiration date. 
This allows different passwords to be simultaneously 
valid. Also, while one password is expiring, at least one 
other password is unexpired, eliminating the necessity of 
shutting the item down when the password is changed. 
This aspect of the invention allows access to the item 
when any of the users supplies any one of the passwords 
before the password supplied has expired. 

[0011] jhis embodiment notifies all of the users when each pass- 
word expires. Also, the invention makes the expiration 
date for additional passwords different than the expiration 
dates for any other passwords when allocating additional 
passwords to the users. The invention can reset the expi- 
ration dates of the passwords, such that the expirations 
dates are evenly spaced in time. If, during the process of 
allowing access, one user enters an expired password 
prior to entering an unexpired password, the invention 
notifies the user that the expired password has expired 
after the user has entered the unexpired password. 

[0012] Also, when dealing with situations where a plurality of 

users share the same userid and the same password, the 



invention maps information associated with tlie users to 
the password in a data file and periodically updates the 
data file. This embodiment also notifies the users of the 
expiration of the password a predetermined time period 
before the password expires. The invention can periodi- 
cally contact the users to confirm accuracy of the infor- 
mation within the data file. The invention can also notify 
at least one corresponding third party identified in the 
data file if the user is denied access to the item because 
of an invalid password. 
[0013] Thus, the invention is useful in an environment where 

multiple software applications share a common user iden- 
tifier (userid). These applications store the userid's pass- 
word in persistent storage (e.g., in a file or in memory). 
Coordinating the changing of passwords in this environ- 
ment is difficult. The invention mitigates the password 
coordination problem by having multiple valid passwords 
for a userid. By stratifying the expiration dates of these 
passwords across time, it is no longer necessary to coor- 
dinate each application's use of a password to occur at the 
same time. Another solution for mitigating the password 
coordination problem is achieved through centralized 
password control and management. In this embodiment, a 



centralized encrypted table maps application information 
to each of its userids and the valid password of the userid. 
Any changes to a userid's password is controlled centrally 
and automatically distributed to the corresponding appli- 
cation's persistent storage. 
[0014] These, and other, aspects and objects of the present in- 
vention will be better appreciated and understood when 
considered in conjunction with the following description 
and the accompanying drawings. It should be understood, 
however, that the following description, while indicating 
preferred embodiments of the present invention and nu- 
merous specific details thereof, is given by way of illustra- 
tion and not of limitation. Many changes and modifica- 
tions may be made within the scope of the present inven- 
tion without departing from the spirit thereof, and the in- 
vention includes all such modifications. 
Brief Description of Drawings 

[0015] Figure 1 is a flowchart illustrating steps for locking out 
userids; 

[0016] Figure 2 is a flowchart illustrating steps for locking out 
userid based on variable weight lockout count; 

[0017] Figure 3 is a schematic diagram of an on-demand com- 
puting environment; 



[0018] Figure 4 is a schematic diagram illustrating why userids 
are shared across applications; 

[0019] Figure 5 is a flowchart illustrating steps for creating a 
userid with a plurality of passwords; 

[0020] Figure 6 is a flowchart illustrating steps for password 
change when a plurality of passwords are present; 

[0021] Figure 7 is a flowchart illustrating steps for password au- 
thentication when a plurality of passwords exist; 

[0022] Figure 8 is a flowchart illustrating steps for password 

change when password usage is managed centrally using 
the centralized password management tool (CPMT); 

[0023] Figure 9 is a flowchart illustrating steps for advance noti- 
fication of passwords soon to expire; 

[0024] Figure 10 is a flowchart illustrating steps for ensuring 
consistent password usage; 

[0025] Figure 11 is a flowchart illustrating steps for monitoring 
systems logs to encourage proper usage of passwords; 

[0026] Figure 12 is a flowchart illustrating steps for stratifying 
password expiration dates; 

[0027] Figure 13 is a table illustrating one embodiment of the in- 
vention; and 

[0028] Figure 14 is a hardware description of the invention. 
Detailed Description 



[0029] Many computer operating systems are designed to loclc a 
userid (disable its password) wlien multiple attempts are 
made to login using invalid passwords. This approach im- 
proves security by minimizing the probably of unautho- 
rized access due to a variety of hacker techniques such as 
automated dictionary attacks and guessing passwords by 
trying commonly used passwords such as birthdays, 
names of relatives, etc. 

[0030] One method for lockout is summarized in Figure 1. In 

block 100, the user identifier (userid) attempts to access 
the system (or system resource) through the provision of a 
userid and password. Block 102 checks to see if the en- 
tered password is valid. If the password is valid, access is 
granted and the userid's lockout count is reset to zero 
(block 104). If the password is invalid, access to the sys- 
tem is denied (block 106) and the lockout count for that 
userid is incremented by one (block 108). Block 110 
checks to see whether an invalid password has been en- 
tered for that userid too many consecutive times. The 
lockout count for the userid is compared with the maxi- 
mum number of permitted consecutive invalid passwords. 
Typically, the maximum number of permitted consecutive 
invalid passwords ranges between two and six. If the 



lockout count exceeds the maximum, the userid is loclced 
out (blocl< 112) which means the userid's password is re- 
vol<ed. No more access is permitted via that userid until 
the userid's password is reset. Conversely, if an invalid 
password has not been entered too many consecutive 
times, then the user is denied access to the system re- 
source and notified (block 114). 
[0031] While this conventional method's "lock out" mechanism is 
designed to prevent nefarious entry, more often, it dis- 
ables userids due to innocent human error. For example, a 
human may forget that the old password has expired and 
stubbornly retry it a few times, perhaps thinking he may 
have made typing errors. As another example, a human 
may think there is a "systems network problem" and retry 
an application every hour (not realizing that the applica- 
tion is failing due to an invalid password). In other words, 
the conventional lockout method hinders the "good guys" 
as well as the "bad guys." Userid lockouts are inconve- 
nient for application users and expensive to administer. 
According to some estimates, between 20% to 50% of all 
help desk calls are for password resets, and the average 
help desk labor cost for a single password reset is about 
$40. For professionals waiting on hold for a help desk 



person, the implied cost of password resets is even 
higher. 

[0032] Jo mitigate the adverse affect due to invalid (but inno- 
cent) passwords, the present invention increments a lock- 
out count by a variable weight based on comparison of a 
submitted invalid password relative to a valid password. 

[0033] The present invention mitigates the problem of userids 

being locked out due to human error. The invention iden- 
tifies invalid logon attempts which are likely to be due to 
human error and weights these with lesser magnitude 
than those logon failures more likely to stem from hostile 
intrusion. Consequently, while the conventional methods 
may revoke a userid's password after say four failed at- 
tempts, the present invention will revoke the userid after 
say 20 failed attempts which are likely due to human error 
or three failed attempts which do not appear to stem from 
human error. Thus, while security is maintained, fewer 
lockouts will occur. This minimizes inconvenience and in- 
efficiency due to innocent human error without sacrificing 
security. 

[0034] More specifically, the invention presents a sophisticated 
method of authorizing access to an item (such as a data 
file, a server, a system, a network, a room, a building, a 



vehicle, or any other "item" that can be protected by pass- 
word). This processing begins by receiving a presented 
password (symbols, numbers, characters, sounds, tones, 
pulses, etc. entered via a signal line, keyboard, keypad, 
touch pad, audio receiver, light receiver, etc.) from an en- 
tity or user desiring access to the item. In this case an en- 
tity or "user" can comprise individuals, software applica- 
tions, application owners, etc. The invention compares the 
presented password with a stored password and autho- 
rizes access if the presented password exactly matches 
the stored password and denies access if the presented 
password fails to exactly match the stored password. 
Those skilled in the art will recognize that some security 
systems store the valid password only in encrypted form; 
such systems compare the encrypted form of the pre- 
sented password with the stored encrypted password and 
authorize access only if the encrypted passwords exactly 
match. It will be obvious to those skilled in the art that all 
references herein to comparisons of stored and presented 
passwords apply also to comparisons of encrypted stored 
and encrypted presented passwords. The invention main- 
tains a lockout count and blocks access to the item if the 
lockout count exceeds a predetermined value. The differ- 



ence between denying access and blocking access is tliat 
the "denying" process allows additional potentially valid 
passwords to be presented after an invalid password is 
presented, while the "blocking" or "lockout" process pre- 
vents any additional passwords from being presented 
(even if they are valid passwords). 
[0035] One embodiment of the present invention is summarized 
in Figure 2. In block 200, the user identifier (userid) at- 
tempts to access the system (or system resource) through 
the provision of a userid and password. Block 201 checks 
to see if the entered userid has been locked out. If the 
userid has been locked out, then block 203 notifies the 
user or system attempting access that the userid has been 
locked and the userid's password needs to be reset. If the 
userid has not been locked, then block 202 checks to see 
if the entered password is valid. If the password is valid, 
access is granted and the userid's lockout count is reset to 
zero (block 204). If the password is invalid, access to the 
system is denied and the user or system attempting ac- 
cess is notified that the password is invalid (block 206). 
Furthermore, if access is denied, blocks 208 and 210 im- 
plicitly examine the probability of the incorrect password 
stemming from an innocent human error. Block 208 



checks to see if the incorrect password is the same as a 
password entered for the userid during a previous speci- 
fied duration of time, say during the past two months as 
an example. If the password was entered for that userid 
during that recent period of time, then it is highly likely 
that the userid/password attempt was innocent. For in- 
stance, the user may have repeatedly entered a password 
which belonged to another of his userids. In such situa- 
tions of a repeated incorrect password, there is no need to 
increase the lockout count and processing proceeds to 
deny login and notify the user 209 so that the user can 
make another password attempt 200. However, if the 
password is not a repeat, the invention proceeds to block 
210. 

[0036] Thus, the invention "variably" increments the lockout 

count if the presented password fails to exactly match the 
stored password. In this process, the invention increments 
the lockout count different amounts depending upon how 
closely the presented password matches the stored pass- 
word. Thus, with this feature, the lockout count is incre- 
mented a lesser amount as the presented password 
matches the stored password more closely and is incre- 
mented a greater amount as the presented password 



matches the stored password less closely. Further, the in- 
vention has the ability to not increment the lockout count 
at all if the presented password is the same as a previ- 
ously presented password that was entered within a pre- 
determined previous time period. 
[0037] In block 210, the (invalid) entered password is compared 
with the valid password for the userid. This comparison 
involves identifying the similarity between the two pass- 
words. The higher the similarity between the two pass- 
words, the lower the value of the variable weight which 
will be added to the lockout count. For instance, a com- 
mon typographical error results from typing the charac- 
ters of a password in an incorrect sequence (e.g., transpo- 
sition errors, etc.). This may be identified by attempting to 
swap each adjacent pair of characters in the entered pass- 
word and checking if the pairwise interchange results in 
the valid password. If a pairwise interchange results in the 
valid password, then it is highly likely that the incorrect 
password entry was due to a typographical error. In this 
case, the lockout count is increased in block 214 by a 
variable weight less than one (say by 0.1 as an example). 
If the pairwise interchange does not result in a valid pass- 
word, the invention can check for another type of typo- 



graphical error. Another common error would be some- 
body inputting an extra character in the password. This 
could be checked by removing a character from the en- 
tered password and checking if the valid password results 
(try this for each character). If the valid password results 
from the removal of any character from the entered pass- 
word, block 2 14 will increase the lockout count by a vari- 
able weight less than one. In this case, it may be appro- 
priate to use a variable weight of say 0.2. To the contrary, 
if no characters of the entered password match the stored 
password, the lockout count could be incremented by 1.0 
or a higher number. The intention is to use variable 
weights which are higher when the probability of the 
password being entered by typographical error is lower. 
The pairwise interchange and character removal ap- 
proaches are simply two (of many) ways of examining the 
similarity of passwords and the implied probability of hu- 
man error. Other ways of estimating the similarity/prob- 
ability include, for example, identifying incorrect use of 
capital letters (e.g., when the password is correct, but is 
inconsistent with the uppercase and lowercase of the 
password), identifying missing characters (e.g., when the 
characters used are the correct characters and are in the 



correct order, but one or more characters are missing), 
and many others that would be obvious to one ordinarily 
skilled in the art given this disclosure. 

[0038] Thus, when determining how closely the presented pass- 
word matches the stored password, the invention evalu- 
ates whether the difference between the presented pass- 
word and the stored password relates to common typo- 
graphical errors. Further, when determining how closely 
the presented password matches the stored password, the 
invention classifies the difference between the presented 
password and the stored password into different types of 
password errors and these different types of password er- 
rors cause the lockout count to be incremented by differ- 
ent values. For example, the different types of password 
errors can include missing characters, extra characters, 
transposed characters, incorrect upper or lower case us- 
age, no matching characters, one-quarter matching char- 
acters, one-half matching characters, etc. 

[0039] Further, the different errors could receive different 

weights when increasing the lockout count. Therefore, an 
incorrect capitalization might only increase the lockout 
count by 0.1, typographical errors, such as transposition, 
etc. might increase the lockout count by 0.3, while other 



more questionable errors, such as missing or extra letters, 
might increase the locl<out by 0.5. The invention is not 
limited to these exemplary errors, but instead is useful 
with any type of error which tends to indicate that the use 
of the incorrect password is not malicious, but is simply 
an incorrect data entry. Further, while the weighting is 
shown as 0.1-0.5, above, any weighting system could be 
used with the invention. 

[0040] If there is no observed similarity between the entered and 
valid passwords, then block 212 increments the lockout 
count by one or a higher number. Both blocks 212 and 
214 lead to block 216 which checks to see whether the 
lockout count has exceeded the maximum number per- 
mitted. If the lockout count exceeds the maximum, the 
userid is locked out (block 218) which means the userid's 
password is revoked. The user is denied access and noti- 
fied of the incorrect password 217 and given another at- 
tempt to enter a password 200. No more access is permit- 
ted via that userid until the userid's password is reset if 
the lockout count has not been exceeded. 

[0041] In contrast to the present invention, conventional meth- 
ods, such as U.S. Patent 5,944,825 (incorporated by refer- 
ence), describe the concepts of lockout and password ex- 



piration. Also, U.S. Patent 5,699,514 (incorporated by ref- 
erence) is different tlian tlie invention and attempts to 
minimize liuman inconvenience due to password locl<out 
by liaving a two tiered locl<out. If the user fails to enter a 
short password correctly for X consecutive times, he may 
gain access and restore his password by entering a longer 
password correctly. Since the second tier's required pass- 
word is long, it is not as vulnerable to hacker dictionary 
attempts, while its existence is less inconvenient to the 
user than a password reset. 
[0042] U.S. patent 6,202,158 (incorporated by reference) is also 
distinguished from the present invention in that this 
patent presumes that since a given user cannot be in two 
places at the same time, multiple accesses of a userid/ 
password from more than one geographical location 
within a short period of time indicate illegal access. An- 
other patent that is contrary to the invention is U.S. Patent 
application 2003/0149900A1 (incorporated by reference) 
that provides preferential lock out treatment for users 
who have logged on successfully in the past. Similarly, 
U.S. patent application 2002/0067832A1 (incorporated by 
reference) allows "forgiveness" of incorrect password at- 
tempts by a person later entering a correct password. An- 



other method that is different than the present invention 
is shown in U.S. Patent 5,375,244 (incorporated by refer- 
ence), which estimates a probability of an illegal resource 
access attempt by comparing a profile of the attempt with 
profiles of known fraudulent users. Profiles include: geog- 
raphy, time of day, type of station, number of simultane- 
ous sessions, etc. No known conventional method in- 
creases the lockout count as a function of the similarity 
between an incorrect and correct password as the inven- 
tion does. 

[0043] Traditionally, most applications were designed to run on a 
single computer system under a single user identifier 
(userid). On occasion complex applications were built to 
run on multiple computer systems to share the loads but 
this was the exception rather than the rule. However, re- 
cent improvements in "middleware" have facilitated an ex- 
plosion in software applications which utilize data and 
processing on a variety of systems and platforms. Fur- 
thermore, the reusability of software objects and data di- 
rectories results in an enormous sharing of software, data, 
and hardware across many applications. This complexity 
and integration is expected to increase in the future. 

[0044] In an on-demand corporate environment / data centre. 



many software applications run in automated and semi- 
automated fashion. All the applications need access to in- 
formation which is secured via userid and password. Dif- 
ferent applications have different access levels for differ- 
ent resources each with its own userid and password. 
Typically, these applications share userids and are dis- 
tributed and access information on multiple servers and 
some run for long durations. They store the userid and 
passwords in persistent storage (e.g., database, property 
file). While the applications are running, the userids and 
passwords may be stored in a memory cache. 

[0045] Figure 3 provides a high level overview of some aspects of 
an on-demand corporate environment. Blocks 306 and 
308 are protected computer resources such as servers or 
data bases. These resources are accessed by users (block 
300) and by applications (block 304) running on a com- 
pute server farm/grid 302. An application may access a 
plurality of protected resources and a protected resource 
may be accessed by a plurality of applications and users. 

[0046] Figure 4 is an illustration that explains by example why 
userids are shared by applications. In the example, end- 
users at front-end web clients (block 400) authenticate to 
web-servers (block 402) using their individual web- 



session userids. Once session-authentication is com- 
pleted the web servlets execute the application function- 
ality. When accessing the backend database (block 404) 
the web servlets will authenticate using the application's 
shared database userid. It is impractical to provide each 
end user with an individual database userid because it 
makes management of the database onerous; every time a 
new userid is created or an old one deleted, all appropri- 
ate database accesses are granted or denied to that 
userid. Even worse, every time a table is dropped and 
recreated, all appropriate database accesses are granted 
or denied to all userids that access that table. To mitigate 
these problems, in practice, userids are shared across ap- 
plications. Note, that throughout this document, the 
userid-password mechanism of authentication is men- 
tioned in order to simplify the explanation. Those skilled 
in the art will recognize that the invention is equally ap- 
plicable to other authentication mechanisms such as digi- 
tal certificates. 

[0047] Security has always been, and will continue to be an im- 
portant factor to be considered when accessing a com- 
puter system. In order to ensure that a user logging onto 
a computer system is bona fide, the target computer sys- 



tern typically does user-authentication before granting 
access, say for example by doing userid-password verifi- 
cation. Similarly, a process on one computer system that 
is interacting with another computer system is considered 
by the target computer system to also be just another 
user, and user-authentication is done in that case too, 
before granting access. 

[0048] It is a problem to change passwords per password main- 
tenance rules of large secure enterprises. All the running 
applications first have to be stopped before passwords are 
changed. All the users sharing those passwords have to 
be notified (so that they do not use an old expired pass- 
word). The passwords in persistent storage have to be 
changed and the applications restarted. This has to be co- 
ordinated across the enterprise. Coordinating downtime 
of on-demand server applications is time consuming for 
programmers and administrators and inconvenient for 
users who expect 24x7 availability. 

[0049] Note further, that it is not mandatory that the calling pro- 
cess and the called process reside on separate computer 
systems. It is entirely possible that they could be running 
on the same computer system, yet the system design may 
require that they run under different userids. This means 



that if a process is running cliild processes under a differ- 
ent userid (on the same computer system or another 
computer system(s)) it needs a userid-password combina- 
tion for each of those computer systems. That in itself, 
providing a userid-password combination for each target 
computer system every time a process is first set up, may 
not appear at first glance to be an onerous task. Unfortu- 
nately, in any reasonably complex application, providing 
an individual userid for each process that needs to access 
a computer system is impractical. Often, processes that 
access a computer for similar functionality will end up us- 
ing the same userid-password when accessing that com- 
puter. 

[0050] The password management task becomes harder when 

the following factor is considered. To combat the menace 
of unauthorized access, it is advised that after a reason- 
able period of time the password of a userid be changed. 
Many organizations require that passwords expire after 90 
or 180 days. This means that after the expiry period, if a 
login is attempted, the target computer system immedi- 
ately prompts for a new password. If the password- 
change protocol is not followed, the login is aborted and 
access is denied (which means the application functional- 



ity will fail). This also means that every time the password 
is changed, all processes that use this userid-password 
combination need to be updated with the new password. 
This is difficult since the remote application processes 
may not even be easily accessible to the owner/ 
administrator of the userid whose password is being 
changed. As a result, a situation may arise where one or 
more processes would attempt to access a computer us- 
ing an old password, and the access would then be de- 
nied, causing the application functionality to fail. 
[0051] As shown above, again for security reasons, many com- 
puter operating systems are configured to "lock" a userid 
if multiple attempts are made to login using invalid- 
passwords. Once the userid is locked, all attempts to ac- 
cess the computer using that userid are denied irrespec- 
tive of whether the password used is correct or incorrect. 
Many of organizations require that the userid be locked 
after the 3rd or the 5th invalid attempt. This exacerbates 
the problem of userid-password maintenance. One or 
more processes with the invalid password would likely 
make multiple attempts to access the computer and lock 
the userid. Subsequent to locking, even processes with 
the valid password would be denied access. 



[0052] In large complex systems, the combination of frequent 

password changes and shared userids often results in re- 
peated catastrophes. Every time the password of a userid 
is changed, the configuration files (or other persistent 
storage) of all the other processes that use this userid 
must be updated. If even one process is forgotten and its 
configuration file is not updated with the newest pass- 
word it could end up locking the userid for all processes. 

[0053] To overcome the above problems, the invention provides 
an easily managed mechanism for password administra- 
tion which does not require on-demand applications to be 
shut down during a password change. This is accom- 
plished by allowing a single userid to have multiple pass- 
words that expire at different times. Each of these pass- 
words can be active at the same time, and each would 
have a different expiration date. When an application at- 
tempts to access a resource, it provides a userid and mul- 
tiple passwords; as long as one of these passwords is 
valid, access is granted. 

[0054] The invention sets password expiration dates so that they 
meet corporate security guidelines and are stratified 
across time. By staggering the expiration dates, the pass- 
words may be changed when convenient without impact- 



ing the 24x7 service windows of tlie on-demand applica- 
tions. As long as one of tlie application's passwords re- 
mains valid, access to the resource is granted. The pass- 
words in persistent storage will be updated following the 
change of a password so that the next time the applica- 
tion is restarted, the new password will take affect. 
[0055] Thus, the invention provides a method for multiple appli- 
cations sharing userids/passwords wherein a single userid 
may have a plurality of passwords, each with different ex- 
piration dates. The invention is especially useful for ac- 
tions taken by systems administration programs during 
new userid creation, change of password, and password 
authentication during login or other attempt to access a 
secure resource. The invention allocates a plurality of the 
same passwords to a plurality of users who share the 
same userid. The invention allows continuous operation of 
the item being accessed by providing that each of the 
passwords has a different expiration date. This allows dif- 
ferent passwords to be simultaneously valid. Also, while 
one password is expiring, at least one other password is 
unexpired, eliminating the necessity of shutting the re- 
source down when the password is changed. This aspect 
of the invention allows access to the item when the any of 



the users supplies any one of the passwords before the 
password supplied has expired. 
[0056] The creation of a new userid is outlined in Figure 5. In 

block 500, the user requests a new userid. In this embod- 
iment, block 502 prompts the user to specify the number 
of passwords desired for the userid being created or 
modified. For ease of explanation, and without loss of 
generality, the following example uses three passwords 
that are chosen to exist for each userid and presumes that 
corporate guidelines require each password to be changed 
every 60 days; however, as would be understood by one 
ordinarily skilled in the art any number of passwords and 
any time periods will be operable with the present inven- 
tion. Block 504 sets the expiration dates of the three 
passwords so that their expiration dates are stratified 
across time. In this example, the three passwords will ex- 
pire in 40, 50, and 60 days respectively. These expiration 
times are chosen to respect the preference to balance the 
desire to change passwords infrequently with the desire to 
have a comfortable period of time between password ex- 
pirations. Other expiration times could be chosen in alter- 
native embodiments. Block 506 provides the user with the 
mechanism to enter a password associated with each of 



the three expiration dates. 

[0057] Figure 6 outlines the one embodiment involved when the 
user changes a password. In block 600, the user requests 
the system to change the password. The system prompts 
the user for the password to change in block 602. When 
the user enters the password, it is compared with the list 
of valid passwords in block 604. If the user entered pass- 
word matches one of the valid passwords for the userid, 
then the system would replace that valid password with a 
new password the user enters and use any of a variety of 
methods to assign a new expiration date for that new 
password (block 606). One of the methods simply sets the 
expiration date to the current date + 60 days (where the 
number 60 can vary along with the organization's policy 
as will be readily apparent to one skilled in the art). The 
system will provide feedback to the user as to the userid"s 
passwords and their expiration dates. Thus, this simple 
embodiment allows the user to stratify the passwords" 
expiration dates across time by manually stratifying the 
dates on which the user changes the passwords. So long 
as the user stratifies the dates of the password changes, 
the passwords" expiration dates will be stratified. 

[0058] An alternative embodiment of block 606 is illustrated in 



Figure 12. In this alternative embodiment, the new pass- 
word's expiration date is determined with an objective of 
systematically (and automatically) stratifying the expira- 
tion dates of the userid's passwords across time. In this il- 
lustrative embodiment with three passwords, the user is 
changing one, leaving two others unchanged. From the 
expiration dates of these two other passwords, block 
1201 calculates earlier.pw as the earlier of the other two 
passwords" expiration dates and later_pw as the later of 
the other two passwords" expiration dates. Block 1202 
checks to see if the later_pw is earlier than today +51 
days. If it is, then block 1206 sets the expiration date of 
the new password to today + 60 days. Otherwise, block 
1203 calculates the difference between the two expiration 
dates as later.pw earlier_pw. Block 1204 compares the 
difference with one embodiment number of 20. (Those 
skilled in the art will recognize that other numbers can be 
used.) If the difference between the expiration dates is 
less than 20, then block 1207 sets the expiration date of 
the new password to ten days earlier than the earlier.pw. 
Otherwise, block 1205 sets the expiration date of the new 
password to be about halfway between the earlier.pw and 
later_pw (i.e., sets it to earlier_pw + half of the difference 



between the password expiration dates and rounds to tlie 
nearest date). Thus, this portion of the invention evens 
out the times between when each of the passwords will 
expire, and other similar methodologies could be used to 
similarly stratify the expiration times. 
[0059] Figure 7 outlines one embodiment for password authenti- 
cation when there are multiple passwords. In block 700, a 
user or application program attempts to log on to the sys- 
tem or access a secure computer resource. Block 702 
checks how many passwords were entered. The multiple 
passwords can be entered sequentially (e.g., if the first 
does not allow access, subsequent passwords could be 
entered, one at a time) or all passwords can be entered si- 
multaneously. 

[0060] If one password was entered, then block 704 checks if the 
entered password was correct (i.e., matches an existing 
valid password that has not expired) and authorizes or 
denies login with notification accordingly (blocks 720 and 
708 respectively). If more than one password was entered, 
then block 706 examines whether all the entered pass- 
words are valid. If all the entered passwords are valid, 
then block 720 authorizes the login; otherwise, block 710 
examines whether all of the multiple passwords entered 



are invalid. If all of the multiple passwords entered are in- 
valid, then the login is denied and the user or application 
is notified of the access denial and its cause (block 708) 
and processing returns to item 700 to allow another pass- 
word to be attempted. 
[0061] Block 712 executes under the condition when multiple 
passwords are entered and some of them are valid and 
others are invalid. If block 712 determines that an invalid 
password has been expired more than a predetermined 
time period (say 5 days ago), then the person responsible 
for administering the application using that expired pass- 
word is electronically notified that the password expired 5 
days ago and needs to be changed (block 714). If any of 
the entered passwords are valid, the login is authorized 
(block 720). 

[0062] Thus, this embodiment notifies all of the users when each 
password expires. Also, the invention makes the expira- 
tion date for additional passwords different than the expi- 
ration dates for any other passwords when allocating ad- 
ditional passwords to the users. The invention can reset 
the expiration dates of the passwords, such that the expi- 
rations dates are evenly spaced in time. If, during the pro- 
cess of allowing access, one of the users enters an ex- 



pired password prior to entering an unexpired password, 
the invention notifies tlie user tliat tlie expired password 
lias expired after tlie user lias entered tlie unexpired 
password. 

[0063] Allowing multiple valid passwords for a userid and strati- 
fying their password expiration dates across time allows 
for applications sharing userids to have their set of pass- 
words updated in a convenient manner. No longer will all 
"on-demand" applications be shut down while their 
userid's password is changed. Instead, each of a userid's 
passwords expires at a different time and, thus, each 
password may be changed during a different block of 
time, during which time other passwords are valid. Since 
these blocks of time can be long (e.g., ten days), the 
passwords can be changed by each application's adminis- 
trator at his or her convenience. 

[0064] In contrast to the present invention, U.S. Patent 6,397,337 
(incorporated by reference) provides a mechanism for a 
systems administrator to logon to a userid without know- 
ing the userid's password. This is implemented by having 
the password authentication process check first for the 
userid's password and, that failing, check to see if the en- 
tered password matches the systems administrator's 



password. By analogy, 6,397,337 provides a "master key" 
which opens any userid's door. In contrast, the present in- 
vention provides a set of keys which opens a single 
userid's door. U.S. Patent 5,581,700 (incorporated by ref- 
erence) is similar to 6,397,337 in that a single computer 
may be accessed by a plurality of passwords. U.S. Patent 
5,581,700 provides for a hierarchy of passwords whereby 
as example, the bottom of the hierarchy is the user ac- 
cessing with his password, followed in the hierarchy by a 
system's administrator using his (master key) password, 
followed by the administrator's boss using his (super 
master key) password, etc. 
[0065] U.S. Patent 5,793,951 (incorporated by reference) is dif- 
ferent than the present invention and has a single master 
computer send a series of passwords to a networked 
computer. If one of the passwords is valid, access is 
granted; otherwise, the master computer administrator is 
prompted to provide a valid password and if he so does, 
the password is added to the series of passwords used 
during subsequent access attempts. This patent recog- 
nizes multiple passwords being valid for a computer re- 
source but only in the context of a single master com- 
puter, not in the context of multiple application programs 



using a set of multiple passwords for a single userid. Fur- 
thermore, 5,793,951 does not address the varying expira- 
tion dates of the passwords. U.S. Patent 5,931,948 
(incorporated by reference) discusses a portable computer 
hardware implementation containing a plurality of pass- 
words but only one password per resource accessed. 
Thus, no known conventional method provides a plurality 
of application programs sharing userids/passwords, a 
plurality of passwords per single userid, along with strati- 
fication of password expiration dates. 
[0066] One common aspect of the above embodiments is that 

they are an integral part of the login process. In some sit- 
uations, this may not be politically, administratively, or 
technically feasible. Consequently, an alternative embodi- 
ment for password management which does not require a 
change to the login process is presented. This alternative 
embodiment provides a systematic method for maintain- 
ing and controlling password changes in an environment 
where multiple applications share the same userid. This 
method may be automated and thus facilitates consis- 
tency of remote userid/password access among these 
multiple applications. Furthermore, this provides a 
method for periodically verifying whether the password 



that will be used by a remote-process Is valid. This has 
the potential of trapping Invalid passwords even before 
they are used, thus reducing the chance of a userld get- 
ting locked. 

[0067] jhe heart of the embodiment for centralized password 
management is a table shown In Figure 13, which maps 
information about a userld to Its uses by various applica- 
tion programs. Refer to this table as, "the centralized 
password management table (CPMT)." Each record of the 
CPMT contains userid, userid-hostname (the name of the 
system or server on which the userid exists), userid- 
password (the password of the userid, probably en- 
crypted), userid-expiry (the date on which the useri"'s 
password expires), userld-owner (email address or other 
info required to contact owner of the userld), userld-ex- 
piry-leadtlme (#days prior to userld-explry when the 
userld Is notified of Impending password expiry), userld- 
Invalld-count (counts the number of times by period, say 
month, when login was attempted with an Invalid pass- 
word for the userld), application (name of the application 
or configuration file containing the userld & password; the 
application-name Includes the full directory path. If appli- 
cable, of the application or configuration file), applica- 



tion-host (name of the system or server(s) where the ap- 
plication or configuration file resides), application-owner 
(email address or other info required to contact owner of 
the application or configuration file), application-rule 
(information on how to access and update an applicatio"'s 
usage of the userid-password when the userid-password 
changes; a simple application-rule may indicate whether 
the application should be automatically updated or pro- 
vide email notification to a specified email address when 
the userid-password changes; a more complicated appli- 
cation-rule would provide instructions for executing a 
specified action on the application using a remote agent 
and encryption/decryption approach chosen). The fields 
shown in Figure 13 are merely examples, and one ordi- 
narily skilled in the art would understand that more, less, 
and different fields could be used, depending upon the 
specific application of the invention. 
[0068] Those skilled in the art will recognize that it is possible to 
normalize the CPMT mapping relationships thus, dividing 
the CPMT information into multiple tables, data bases, or 
files. For ease of explanation, we refer to the CPMT as a 
single table recognizing that others may choose to imple- 
ment the relationships using multiple tables. Thus, when 



dealing with situations wliere a plurality of users who 
share the same userid also share the same password, the 
invention maps information associated with the users to 
the password in the CPMT data file and periodically up- 
dates the data file. This embodiment also notifies the 
users of the expiration of the password a predetermined 
period before the password expires. The invention can 
periodically contact the users to confirm accuracy of the 
information within the data file. The invention can also 
notify at least one corresponding third party 
(userid-owner, application-host, application-owner, etc.) 
identified in the data file, if the user is denied access to 
the item because of an invalid password. 
[0069] The CPMT is used in several ways to efficiently manage 
passwords in an on-demand environment where many 
applications share the same userids. One of these meth- 
ods is summarized in Figure 8. In block 800, the pass- 
word change of a userid is initiated. Typically, the pass- 
word change will be initiated by a user though there is 
nothing in the present invention which requires the pass- 
word change to be initiated by a person. In block 802, the 
useri"'s password is changed on its host system or 
server(s). Block 804 changes the userid-password in the 



CPMT. Block 806 uses information in the CPIS/IT to update 
the applications and configuration files which keep the 
userid and associated password in persistent storage. 
Sometimes these application and configuration files reside 
on the same system as the CPMT. In these situations the 
application may be updated directly. In other cases, the 
application and configuration file reside on remote sys- 
tems. In these cases, a remote agent can update the re- 
mote usage of the password in the application or its con- 
figuration file. Optionally, the application-rule contained 
within the CPMT will indicate that an email notification 
should be sent to notify the person responsible for main- 
taining the application or configuration file that the pass- 
word can be changed manually. Whether remote updates 
of application password usage is done automatically or 
manually depends on a number of factors including the 
technical feasibility of an automatic update and the per- 
ceived security threat of allowing automatic updates to 
occur, and all of this would be captured in the appropriate 
application-rule. 
[0070] Figure 9 summarizes one embodiment involved in a pro- 
gram which scans the CPMT for the purpose of providing 
notification of upcoming password expirations. This pro- 



gram is run on a periodic basis (e.g., bi-wee[<ly). Bloclc 
900 reads a record from the CPMT. Blocl< 902 checl<s to 
see if this is the first record processed for the userid/ 
userid-hostname combination. If it is not, then the next 
record is read (blocl< 900). If it is the first CPMT record 
processed for the userid/userid-hostname combination, 
then block 904 sets the warning date equal to the date the 
useri"'s password is scheduled to expire (userid.expiry) 
minus the predetermined lead-time 
(userid-expiry-leadtime). Block 906 checks to see if the 
resulting warning_date has occurred (e.g., if the current 
date is equal to or past the warning date). If it is, then 
block 908 notifies the userid-owner (probably via elec- 
tronic mail) that the useri'"s password is scheduled to ex- 
pire on the userid-expiry date. The intention is to provide 
advance warning so that the responsible person knows to 
change the password prior to its expiration. Furthermore, 
the invention can warn the person responsible for the ap- 
plication programs of the impending need for password 
change by using the appropriate application-rule for noti- 
fication details. In any event, after this CPMT record is 
processed, the program flow returns to block 900 to read 
the next record. Processing stops once all records have 



been read. 

[0071] Figure 10 summarizes one embodiment involved in a pro- 
gram wliicli scans tlie CPMT for tlie purpose of ensuring 
consistent usage of a useri"'s password even before tlie 
application attempts to use the password. In this embodi- 
ment, this program runs on a periodic basis (e.g., daily). 
In an alternative embodiment, it could be implemented to 
be an integral part of the login process and run every time 
an attempt is made to login using a userid with an invalid 
password. The method outlined in Figure 10 processes 
one CPMT record at a time beginning with block 1000 
which reads the next CPMT record. Block 1002 accesses 
information in the application or its configuration file to 
ascertain whether the applicatio"'s stored password is 
consistent with the CPMT userid-password (the latter pre- 
sumed to be the useri"'s valid password). If the application 
resides on a remote system, accessing its password may 
require using information encoded in the corresponding 
CPMT application-rule. If block 1004 identifies inconsis- 
tent passwords, then block 1006 notifies the userid- 
owner and application-owner. In any event, after the 
CPMT record is processed, the program flow returns to 
block 1000. Processing stops once all CPMT records have 



been read. 

[0072] Figure 11 summarizes one embodiment involved in a pro- 
gram wliicli scans tlie CPMT and tlie system logs for the 
purpose of ensuring consistent usage of a useri"'s pass- 
word. In this embodiment, this program is not allowed to 
be implemented as an integral part of the login process 
and therefore can be run on a periodical basis (say once a 
day). In the method outlined in Figure 11, block 1101 
processes the system logs to find instances of failed login 
attempts due to invalid passwords. When such instances 
are found, block 1103 reads the CPMT. Block 1104 checks 
if the userid is maintained in the CPMT, and if so, block 
1105 notifies the userid-owner and application-owner 
which allows for the useri'"s password and usage to be 
proactively maintained instead of waiting until the userid 
gets locked. It could also keep a count of the invalid us- 
age in the userid-invalid-count field which would provide 
metrics of invalid usage. This would allow system and ap- 
plication support personnel to proactively make decisions 
for supporting the userid. 

[0073] To contrast with the present invention, U.S. Patents 
6,601,173; 6,240,184; 5,682,475; and 6,240,184 
(incorporated by reference) refer to password control for 



multi-system usage by a single authorized user. For in- 
stance, U.S. Patent 6,240,184 provides a system, method, 
and data structure for securely synchronizing passwords 
used by a single user across multiple systems. However, 
unlike the present invention, none of these conventional 
methodologies involve userids being shared across multi- 
ple applications. 

[0074] The inventive method for central management of pass- 
words keeps track of all usages of userid/password. The 
method automatically synchronizes these usages when 
passwords change. The method periodically verifies that 
all usages are consistent. The method provides pre- 
notification and post-notification. The method also pro- 
vides usage metrics. 

[0075] A representative hardware system and structure for prac- 
ticing the present invention is depicted in Figure 14. This 
schematic drawing illustrates a hardware configuration of 
an information handling/computer system in accordance 
with the subject invention. This system includes at least 
one processor or central processing unit (CPU) 10. The 
CPUs 10 are interconnected via system bus 12 to various 
devices such as a random access memory (RAM) 14, read- 
only memory (ROM) 16, and an input/output (i/O) adapter 



18. The I/O adapter 18 can connect to peripheral devices, 
such as disk units 20, tape drives 22, or other program 
storage devices that are readable by the system. The sys- 
tem can read the inventive instructions on the program 
storage devices and follow these instructions to execute 
the methodology of the invention. A user interface 
adapter 24 connects a keyboard 26, mouse 28, speaker 
30, microphone 32, and/or other user interface devices to 
the bus 12 to gather user input. In addition, a communi- 
cation adapter 34 can connect the information handling 
system to a data processing network, and a display 
adapter 36 connects the bus 12 to a display or other simi- 
lar output device 38. 

[0076] It should be understood by those of ordinary skill in the 
art, however, that the present invention is not limited to 
the above implementation and is independent of the com- 
puter/system architecture. Accordingly, the present in- 
vention may equally be implemented on other computing 
platforms, programming languages and operating sys- 
tems, and also may be hardwired into a circuit or other 
computational component. 

[0077] While the invention has been described in terms of the 
preferred embodiments, those skilled in the art will rec- 



ognize that the invention can be practiced with modifica- 
tion within the spirit and scope of the appended claims. 
For instance, while the userid-password mechanism of 
authentication is discussed above in order to simplify the 
explanation, those skilled in the art will recognize that the 
invention is equally applicable to other authentication 
mechanisms like digital certificates, etc. Furthermore, a 
Relational Database Management System (RDBMS) is used 
above as a data repository, though applications to other 
forms of data repository will be obvious to those skilled in 
the art. 



